Companies typically provide telephone “call centers” or “contact centers” as a service to their customers. This is particularly so—though not exclusively so—when the company relies upon personalized service to their customers to generate real revenue, or to generate intangible value for the company, such as customer goodwill. For example, financial institutions, such as insurance companies, banks, mortgage companies, and credit card companies may provide telephone call centers with live operators for day-to-day matters. In addition, cable television companies may provide such centers for pay-per-view or other assistance, and other companies may provide centers for automated purchases, for technical assistance, for power outage assistance, for emergency assistance, for travel reservations, for student registration, for lotteries, for participation in television or radio game shows, etc.
The operation of one call center (including both automated and live capabilities) for the benefit of one company in one industry does not remain static. Changes to a call center involving system upgrades, improvements in call handling, interaction, management, processing, or routing are common. One of the parameters that tends to complicate changes is the “size” of a call center, which, in turn, is generally a function of the number of anticipated calls.
Various technologies can form a part of a call center. For example, an “Automated Attendant” system is conventionally a system that connects to a PBX system, a Centrex system, or an Automatic Call Distributor (“ACD”), accepting incoming calls, providing audible prompts to callers, and accepting input from callers. As the name suggests, an Automated Attendant seeks to automate the functions of a live telephone operator (or “attendant”).
Before the advent of modern call centers, a live switchboard operator would briefly answer calls by asking the caller who they wished to speak to or what department to be connected to. After the caller made his request, the live switchboard operator would route the call to the requested destination and drop off the line. In a similar manner, and with respect to the Automated Attendant systems discussed above, the input that is accepted by an Automated Attendant may be used to provide another prompt to the caller, terminate the call, or it may be used to allow the caller to self-route the call to some destination.
FIG. 1 depicts an exemplary prior-art Automated Attendant system 140 connected to PBX 155. Automated Attendant system 140 includes Voice Node 144, Control Node 142, Database 145, and may include Reporting Engine 148. As will be discussed in more detail below, Reporting Engine 148 may be used to write to Call Log 150 and/or create a string of parameters associated with a particular call.
PBX 155 is also connected to customer service representative stations (CSR stations) 171, 172, and 179. Each of the CSR stations includes a workstation that may be connected over a Network 180 to Customer Database 190.
FIG. 2 depicts an exemplary call flow that the hardware in FIG. 1 may implement. A call from Remote Terminal 100 may be routed over PSTN 110 to PBX 155. When PBX 155 receives the call, it initially routes the call over Line 162 to Automated Attendant system 140. One manner in which this is accomplished is by Call Vectoring and Vector Directory Numbers (VDNs), as described, for example, in U.S. Pat. No. 5,206,903 to Kohler et al. The chosen VDN corresponds to the connection represented by Line 162 to Automated Attendant system 140 and a series of logical decisions carried out by Control Node 142. If Automated Attendant system 140 is integrated in PBX 155, then Line 162 may correspond to an internal bus line.
When Voice Node 144 receives the call, it may, under the control of Control Node 142, provide an audible message or prompt to the caller. In FIG. 2, for example, steps 200 and 205 include a general greeting (step 200) and a general introduction to certain menu options (step 205). Although the next step 210 is depicted as collecting DTMF data from the caller, Voice Node 144 may be programmed to continually test or be responsive to incoming DTMF signals, with corresponding responses available under the control of Control Node 142.
One of the simplest operations available, however, is to transfer the caller to the appropriate CSR. In FIG. 2, for example, should the caller enter DTMF tone “1” on the remote terminal, Control Node 142 is programmed to formulate a transfer operation to an agent in CSR group 1. This may be accomplished in a variety of ways. For example, if Line 162 represents an analog POTS line, Voice Node 144 may generate a “FLASH” signal, and then enter the appropriate command and extension that PBX 155 recognizes as a command to transfer the instant call to a particular extension. This may be accomplished, again, by VDNs. For example, under the “FLASH” transfer discussed above, Voice Node 144 may generate DTMF tones to tell PBX 155 to transfer the call to extension “1234.” Moreover, as with incoming calls, PBX 155 may be programmed such that requests to reach extension “1234” get mapped to “VDN xx1,” which corresponds in FIG. 1 to CSR station 171. The result is that the call no longer terminates on Automated Attendant system 140, but is transferred to an available CSR agent located at VDN xx1. Again, the “FLASH” transfer technique discussed above is only exemplary. If a digital connection is available, the command to pull the call from Automated Attendant system 140 and send it to VDN xx1 may be made through an out-of-band data connection.
Database 145, as depicted in FIG. 1 contains stored data, such as the audio files associated with the greetings, the prompts, and the messages. Control Node 142 includes the logic associated with the process of analyzing retrieved data over line 162 and determining the response Automated Attendant system 140 should make as a function of the assigned VDN.
As noted above, Reporting Engine 148 may be used to keep a log associated with the calls that Automated Attendant system 140 handles. Call Log 150 typically includes information associated with each call Automated Attendant system 140 handles, and may be used to index other associated data, such as the CSR group the call is transferred to.
As noted above, an Automated Attendant conventionally has the ability to provide prompts to callers, terminate calls, or allow callers to route the call to some destination. Conventionally, the motivation for the introduction of Automated Attendants was to automate the routing tasks generally performed by a live switchboard operator. Similarly, the traditional use of Automated Attendant systems is not to provide personalized information to callers. Rather, the traditional use of Automated Attendant systems has been to route the callers to a destination at which they can receive the personalized information they desire. In this regard, the most information that may traditionally be provided by an Automated Attendant is information about the telephone circuits themselves, such as the particular telephone extension number that the caller is routed to in a “Dial-by-Name” system.
However, because the operator of the Automated Attendant system may customize the prompt to callers, some Automated Attendant systems provide general information to all callers that call in. For example, an Automated Attendant system may be customized to provide all callers to a business with “Locations and Hours” information, or may be customized by a movie theater to provide movie schedules and costs. The assumption behind this use, however, is that everyone dialing into the telephone number connected to the Automated Attendant system is interested in the same or a similar class of information. While the most requested information may be how to connect to a particular live person that can address the caller's particular issue, it may also be used to provide generally anticipated information as, for example, “Locations and Hours,” movie schedules and costs, etc.
An Automated Attendant system also has the ability to collect data from the caller or from the switch, such as the called number (“DNIS”) or the calling number (“ANI”), or from some other source. U.S. Pat. No. 5,867,562 to Scherer, for example, describes some examples of network data. The Automated Attendant system may be programmed to collect such data in order to populate a computer screen for the agent the call is eventually routed to. The gathering of such data, associating it with a particular call, and using it to populate the computer screen in front of the agent as the call is switched to the agent is generally referred to as Computer Telephony Integration (“CTI”), and the particular operation is generally known as a “screen pop.” FIG. 3 depicts an illustration of how such a process may be achieved using the system of FIG. 1.
Considering, again, the system of FIG. 1, PBX 155 is connected to CSR stations 171, 172, and 179, which are configured to provide the respective agents with screen pops. Each of the CSR stations includes a workstation that may be connected over a Network 180 to Customer Database 190, and is also connected to CTI Manager 160.
Also represented in FIG. 1 is the use of Data Set 146 and Data Set 147 in Database 145. Whereas FIG. 2 illustrated the possible use of one greeting and set of menu prompts, and responses, FIG. 1 depicts the availability of at least two separate sets of greetings, menu prompts, and responses, each associated with a particular DNIS/VDN that Automated Attendant system 140 receives from PBX 155 or from a switch. For example, Data Set 146 is depicted as associated with VDN yy2, and Data Set 147 is depicted as associated with VDN yy1. Again, the illustration is exemplary only. While the greetings, prompts, and messages are depicted as separately stored, the two data sets may equally include data that is common to both, such as a routine message: “please stay on the line while your call is transferred.”
The DNIS that PBX 155 associates with VDN yy1 may be derived from one published number, and the DNIS that PBX 155 associates with VDN yy2 may be derived from another published number. Moreover, the first number may be published for callers to make purchases, while the other number may be published for callers to make service calls. In this sense, the same Automated Attendant system 140 is configured to handle both sets of calls, and Control Node 142 is simply programmed, based upon the DNIS\VDN number, to pull the appropriate data from Database 145, and make the appropriate call flow decisions.
FIG. 3 depicts a process of a screen pop by the system of FIG. 1. The numbers “1,” “2,” “3,” “4,” etc. in FIG. 3 indicate the order in which the process may be executed. As before, a call from Remote Terminal 100 may be routed over PSTN 110 to PBX 155. When PBX 155 receives the call, it may be programmed to connect the call initially over Line 162 to Automated Attendant system 140 using VDN yy1.
When Voice Node 144 receives the call with the associated VDN number, it may, under the control of Control Node 142, provide an audible message or prompt to the caller, and Reporting Engine 148 may write to Call Log 150. In FIG. 3, this process is indicated by the lines labeled “1-6” flowing from PBX 155 to Telephony Server 310 contained within Automated Attendant system 140, between Telephony Server 310 and Call Process Engine 320, between Call Process Engine 320 and Reporting Engine 148, and between Reporting Engine 148 and Call Log 150. In FIG. 3, one skilled in the art should appreciate that Telephony Server 310 and Call Process Engine 320 represent functional modules. Such modules are depicted in this manner merely to schematically isolate functions that are performed by the combination, depicted in FIG. 1, of Voice Node 144, Control Node 142, and Database 145 in Automated Attendant system 140. Such processes and functions, as indicated above, may include a general greeting, a general introduction to certain menu options, the capture of a DTMF signal, and the determination as to what extension (or VDN) PBX 155 should route the call to.
If the system of FIG. 1, based upon the internal vectoring logic, determines that a call should be routed to an available CSR agent associated with a VDN (such as at CSR station 171), then Reporting Engine 148 generates CTI_id 152, and Call Process Engine 320 instructs Telephony Server 310 to send the appropriate command to PBX 155 to route both the call to the VDN, as well as a data value containing the CTI_id 152, such as “zz4.” CSR station 171 then receives the transferred call and the CTI_id data (either in-band or out-of-band). The arrow labeled “7” depicts this. The CT_id, then, may be transmitted to Web Browser (or Thick Client) 384 (which is residing on the workstation located at CSR Station 171) in the process arrow “8.” Web Browser (or Thick Client) 384 then may be programmed to generate a URL including the CTI_id in a request to CTI Manager 160 in order to retrieve any other data associated with the call and located in Call Log 150 (process arrows 9-12). Such additional information then may be sent back to Web Browser (or Thick Client) 384, which may include information (such as ANI information) identifying who the caller is. With this information, the web browser (or thick client) may be programmed to generate a request for customer data that accesses the Customer Database 190 and retrieve the appropriate customer information (process arrows 13 and 14). In this way, as the CSR agent is preparing to speak with the caller on the line, the CSR agent's computer screen may be already populated with the appropriate information, as well as having pulled the customer's data record from the customer database. U.S. Pat. No. 6,934,381 to Klein et al., for example, discloses a system for routing calls to CSRs based upon how the customer contact was received (i.e., Voice over PSTN, e-mail, text chat, VOIP, etc.)
As indicated above, a live customer service representative at a call center generally provides personalized service for callers. Even this function, however, has been found over time to involve responses to similar or redundant requests. For example, while many customers dialing into a bank may want to know the bank's location and hours, many more customers dialing into a bank generally want to know what their current balance is. In this regard, however, while “location and hours” information will apply to all callers dialing into a system, a callers' current balance will, by definition, not apply to all callers, but be personal to the particular caller dialing in.
In order to automate such redundant personalized customer requests, Interactive Voice Response systems (“IVRs”) were developed. IVRs may be generally thought of as a computer with an audio-based interface. Traditionally, an IVR system will provide the caller with audible prompts, and accept DTMF input in response to the prompts. IVRs may be distinguished from Automated Attendant systems, however, in that they are configured to particularly respond to a caller's request for personalized information. This, generally, will involve access to a database of information that is personalized to the caller, and the ability to convert both the caller's personalized input into a request that is understandable by the database software, as well as the ability to convert the information retrieved from the database into an audible signal that will be understood by the caller. FIGS. 4 and 5 depict an exemplary system using an IVR as well as an exemplary call flow depicting information that is typically requested using an IVR.
For example, many customers dialing into a bank will want to know their current balance. As before, a call from Remote Terminal 100 may be routed over PSTN 110 to PBX 155. For example, a user at Remote Terminal 100 may have dialed “1-555-ACME SIX.” When PBX 155 receives the call, it may be programmed to connect the call initially over Line 162 to Automatic Call Distributor (ACD) 445, which may further be programmed to connect the call to IVR 440. Although ACD 445 is depicted as connected to IVR 440, and the CSR stations 471, 472, and 479 are depicted as connected to PBX 155, ACD 445 may also be directly connected to IVR 440 and CSR stations 471, 472, and 479.
When Voice Node 444 receives the call, it may, under the control of Control Node 442, provide an audible message or prompt to the caller. In FIG. 5, steps 505 and 510 indicate this process. In response to caller input, illustrated at step 515, another prompt is given in step 520 “Please enter account number and PIN.” In response to further input, IVR 440, as illustrated in FIG. 4, may be connected to access Customer Database 190 in order to retrieve information that is personal to the caller—such as account balance. Thereafter, as depicted by step 530 in FIG. 5, IVR 440 is programmed to create an audible message to the caller reciting the balance on record.
While a live bank teller can respond to a customer's request and tell the customer his current balance over the phone, an IVR system, as illustrated above, can automate such a task. For example, an IVR system might prompt the caller to enter his account number and some identifying information for security purposes (such as a pass code), to access a database and convert the retrieved information into an audible sentence that can be sent to the caller over the telephone line. For personalized services the IVR cannot accommodate, the system may route a caller to a live customer service representative.
A call center that anticipates many phone calls and that relies on IVRs to handle redundant personalized requests will generally require many duplicated IVR systems and many live customer service representatives in order to handle all the anticipated call volume. In such large-scale environments, call center managers will generally be concerned about certain indicia of efficient resource allocation. For example, the salary of live customer service representatives represents one of the larger overhead costs associated with call centers. Consequently, for efficient resource allocation, there is pressure to reduce this cost, such as maintaining fewer live customer service representatives, and automating as many tasks as possible through IVRs and Automated Attendants. In this regard, an indicator of the efficient use of live customer service representatives is the ratio of the number of customers that get the information they desire from the IVR system to the number of customers routed to live customer service representatives in order to get the personalized information they might be after. Another indicator, of course, is the average amount of time that a caller wishing to speak to a representative spends on hold.
While the average amount of time that a caller wishing to speak to a representative spends on hold will be affected by the number of live customer service representatives available, it is also affected in large measure by how “caller-friendly” the call flow is. For example, if a call flow is too confusing or requires too many DTMF entries to arrive at a frequently requested option, many callers will simply “zero-out” to speak to a live customer service representative. This decreases the ratio of callers that end the call within the IVR, and increasing the “hold time” as well as the number of live customer service representatives that would be necessary to decrease that time. Moreover, if it is easy for callers to take their business elsewhere, and a competitor happens to provides more caller-friendly service, then an unfriendly call-flow can also result in the loss of business.
Because of the importance that small adjustments to call flow can make in efficient and friendly customer experience, and because the personalized service that each business or situation offers is often unique to that business or situation, there is often a need to continually adjust call flow parameters to achieve an efficient and friendly customer-service experience.
For this reason, Automated Attendant systems connected or integrated in PBXs may be configured to provide reporting information to the call center manager to give the call center manager an idea of the progress of calls through the Automated Attendant system. This reporting information may consist of a sessionid, which is a unique identifier assigned to each call handled by the Automated Attendant system, as well as information that reflects the caller's progress through the call flow. Based upon a review of the caller's progress through a call flow, a call center manager may wish to make a slight adjustment to the call flow to more efficiently manage incoming calls.
Especially in businesses which anticipate a large number of callers with a large number of personalized requests, such minor adjustments to call flow can have the largest impact, and the need to continually tailor the call flow in reaction to system upgrades, improvements in call handling, interaction, management, processing, or routing is perhaps greatest. It is in exactly this scenario, however, where a call center manager encounters the problems associated with adjusting a large number of IVR systems operating in parallel. Such changes incur their own cost on the system and on the customer experience. It is often necessary to stage such overall changes to the IVR systems, anticipating that some systems will go down as a result for unforeseen reasons. All of this, again, can simply result in more callers getting disconnected, put on hold, etc.